Traversing of NAT address translation equipment for signaling messages compliant with SIP protocol

ABSTRACT

Method of setting up a communication session between a calling client (C 1 ) and a called client (C 2 ), through a communication network (SN 1 , SN, SN 2 ) containing at least one address translation device (NAT 1 , NAT 2 ). This method contains stages for the transmission of signaling messages (fs), passing through at least one address translation device and allowing the exchange of the physical addresses of the clients. At least one of the clients implements a solution for the traversing of address translation devices. The method is innovative in that at least one client adds, within the sent signaling messages, a parameter representing the implementation of the traversing solution and that, in the presence of such a parameter, the network devices do not implement their own solutions for the traversing of address translation devices.

This invention relates to communication networks. More specifically, itconcerns the problem of the transmission of signaling messages throughaddress translation devices such as “NATs”.

Current communication networks allow a communication session to be setup using signaling protocols such as H.323, MGCP (Media Gateway ControlProtocol) or SIP (Session Initiation Protocol) and SDP (SessionDescription Protocol).

This SIP protocol is defined by RFC 3261 of the IETF (InternetEngineering Task Force) and its dual aim is to allow:

-   -   the connection between two parties,    -   the negotiation of the characteristics of the session to be set        up (video throughput, encoder (CODEC) to be used, etc.), via the        SDP protocol.

A calling party wishing to call another party may address a signalingmessage (“Invite”) to a signaling element, called a “Proxy”, containingits personal address, the physical address of its terminal (or, moregenerally, a client, or a “user agent”) and the personal address of thecalled party. The signaling element has the means (“registrar”) toconnect the personal address of the called party and the physicaladdress of the corresponding terminal. Through this connection, thesignaling message may be routed to the calling party.

If the calling party accepts the call, it then replies with newsignaling messages containing the physical address of the terminal orclient (or “user agent”). Therefore, since each of the two terminalsknows the physical address of the other party, they may set up an IP(Internet Protocol) connection for the transmission of data (voice,video, etc.).

A problem arises however with address translation devices, known by theacronym NAT (“Network Address Translation”) or NAPT (“Network AddressPort Translation”) and defined in RFC 1631, “The IP Network AddressTranslator”, and in RFC 3022 “Traditional IP Network Address Translator(Traditional NAT)”. These devices are intended to interface asub-network (typically, a private network) with the public Internetnetwork. The devices (terminals) of the sub-network have physical IPaddresses for which the validity is limited to the sub-network. When itwishes to set up communication with devices located outside thesub-network, the address translation device assigns it a temporarypublic address, valid for the public network, and memorizes theassociation between the private address of the client and its temporarypublic address.

The NAT address translation device therefore modifies on the fly themessages transmitted between the private network and the public network,by

-   -   converting the private addresses of the terminals to public        addresses, in the IP headers of the outgoing messages, in other        words those going from the private network to the public        network, and by    -   converting the public addresses of the terminals to private        addresses, in the IP headers of incoming messages, in other        words those going from the public network to the private        network.

A problem therefore arises for the traversing of address translationdevices by SIP/SDP (or H.323 or others) signaling messages. This problemis known as “NAT traversing”.

It is for example described in the participative encyclopedia“Wikipedia” at the address:“http://en.wikipedia.org/wiki/NAT_traversing.html” and mentioned in RFC3235 of the IETF, entitled “Network Address Translation (NAT)—FriendlyApplication Design Guidelines”. It has also been set out in the IETFdraft entitled “Considerations for Selection of Techniques for NATTraversing” by J. Rosenberg, published in February 2005.

The signaling protocols, such as SIP and SDP, are considered to beapplication protocols. The SIP/SDP protocol, for example, may betransmitted by the TCP or UDP protocol, themselves located above IP inthe protocol stack. A SIP message is therefore in fact a sequence ofparameters encapsulated in a TCP or UDP message, itself encapsulated inan IP message.

The NAT address translation devices only modify the parameters locatedat IP layer level, leaving intact the parameters located in higherlayers.

In other words, the physical addresses contained in the SIP and SDPmessages are not modified by the address translation devices, unlike theaddresses contained in the IP headers.

As a result, the recipient of the signaling message (the called client)will only know the private address of the calling client. However, sincethis is only meaningful in the private network, the communicationsession cannot be set up.

Since this problem is well known, many solutions have been proposed toresolve it. We may distinguish between two main approaches to resolvethis problem: approaches based on the calling client and approachesbased on a server or device of the communication network.

The first category includes the STUN (“Simple Traversing of UDP throughNATs”) mechanism, described in RFC 3489. This mechanism allows a client(or terminal) to find out its public address. Therefore, prior to theemission of a message to the public network, the calling client sends arequest to a STUN server located in this public network. The serverresponds with a message containing the address (and the port) at whichit “sees” the client, in other words its public address.

The client may then use this public address to indicate, via the SDPprotocol, the address at which it wishes to receive replies.

This solution however suffers from a major limitation, since many NATsare said to be “symmetrical” and associate a public address with a pairof parties. Therefore, the public address assigned by the NAT to theclient may be different for the communication with the STUN server andfor the session to be set up with the other party. In such a case, thecommunication between the client and the other party cannot be set up.

Other proposals, based on the same principle, have been made to improvethe situation, such as TURN (“Traversing Using Relay NAT”) mechanisms.The TURN mechanism is described in the“draft-rosenberg-midcom-turn-09.txt” document, published in March 2006on the IETF site.

However, neither the STUN mechanism nor the TURN mechanism is adapted tothe SIP protocol.

A new mechanism, ICE (“Interactive Connectivity Establishment”) hastherefore been proposed to adapt the traversing of SIP signalingmessages. It is based on an adaptation of the STUN and TURN mechanisms.The ICE mechanism is described in the “draft-ietf-mmusic-ice-10.txt”document, also published on the IETF site in August 2006 and entitled“Interactive Connectivity Establishment: A Methodology for NetworkAddress Translator (NAT) Traversing for Offer/Answer Protocol”.

The second category of solutions is based on devices inside thecommunication network. It should be noted that the first solutionsimplemented a server inside the network (STUN server, for example), butthe initiative was that of the client. In this second group ofsolutions, however, the initiative and the implementation of the NATtraversing solutions belong to a network device.

A first solution belonging to this group is, for example, to associatean application gateway with the NAT address translation device. Thismechanism is known as an ALG (“Application Layer Gateway” or“Application-level Gateway”) and is defined in paragraph 2.9 of RFC 2663entitled “IP Network Address Translator (NAT) Terminology andConsiderations”, published in August 1999.

This gateway (or a NAT with the features of such a gateway) has means ofunderstanding application protocols used by the messages. It can inparticular understand the content of the signaling messages andtranslate the physical addresses contained in the SDP messages so thatthe parties exchange their public addresses and not their privateaddresses, thereby allowing them to set up communication sessions.

A variant of this solution involves using a session controller known asSBC (“Session Border Controller”), which will be placed on the signalingmessage paths. This type of product is used to control the transmissionof the communication sessions and the signaling messages between the twonetworks. More precisely, the SBC may play the role of a SIP “proxy”signaling element which can control the means of media transmission (a“media proxy”) using a protocol such as Megaco so that the communicationsessions are appropriately set up between the parties.

The IETF draft entitled “Functionality of Existing Session BorderController (SBC)”, published in February 2005, describes more explicitlythe operation of an SBC session controller.

Further solutions exist in each of these large categories, without anyone of them standing out definitively above the others.

A single communication network can thus simultaneously implement severalsolutions. A communication client does not a priori know whether thenetwork with which it is associated implements a traversing solution: itmay then implement an ICE type solution whereas the network implementsan ALG or SBC type solution.

The deployment of two solutions is redundant and leads to the loss ofresources, but furthermore the solutions may be mutually disruptive andlead to incorrect operation of the communication network: the addressescontained in the signaling messages may be modified incorrectly, or whenit is not necessary, by the ALG or SBC device. Finally, thecommunication sessions cannot be set up.

This problem does not seem to have been resolved until now.

A solution that may be proposed would be to manually disable themechanisms implemented by a SIP client (ICE, STUN, TURN, etc.) when thisclient known itself to be attached to an SBC or to an ALG gateway.

Such a process is however complex to implement: for a client to knowthat it is attached to an ALG gateway or to an SBC, it must know thetopology of the network of its access provider. In addition, theconfiguration must be manually modified each time that the client isattached to a new network.

Furthermore, this approach is not optimal since once a solution based onan ALG gateway or an SBC is deployed it is, by construction, preferredto the solutions based on the client. However, it is this lattersolution which is generally optimal since it allows the client tocontrol the setting up of the communication session and does notimplement a media relay like SBC or ALG solutions.

The aim of the invention is to overcome these disadvantages by proposinga method for the optimal coexistence of solutions based on the clientsand solutions based on the communication network (ALG, SBC, etc.).

A first objective of the invention is a method of setting up acommunication session between a calling communication client (or “useragent”) and a called communication client, through a communicationnetwork containing at least one “NAT” address translation device.

The method includes stages for the transmission of signaling messages,passing through the address translation device and allowing the exchangeof physical addresses of communication clients for setting up thecommunication session. At least one of the communication clientsimplements a solution for the traversing of address translation devices.

The method is characterized:

-   -   firstly by the fact that at least one of the communication        clients adds, within at least one sent signaling message, a        parameter representing the implementation of the address        translation device traversing solution; and    -   secondly by the fact that, in the presence of such a parameter,        the communication network device does not implement its own        address translation device traversing solutions.

According to some embodiments of the invention, the signaling messagesent complies with the SIP protocol. It may be an “Invite” message, butalso other types of message (“Register”, “Notify”, etc.).

The parameter may be a header which complies with the SIP protocol, or aparameter which complies with the SDP protocol.

The device traversing solution may be a solution belonging to a groupincluding the mechanisms STUN, ICE, TURN, etc.

The invention may also allow, in the absence of the parameter, for thecommunication network device to implement its own address translationdevice traversing solutions.

Furthermore, when a device of the communication network implements itsown traversing solution, it may insert a parameter into the outgoingsignaling message representing this implementation.

The invention also has the objective of a communication client withmeans of sending signaling messages for setting up a communicationsession with at least one other communication client, and means oftraversing address translation devices.

The client according to the invention is innovative in the sense that ithas the means, prior to the sending of a signaling message, to addwithin this message a parameter representing the implementation of thesemeans of traversing address translation devices.

According to some embodiments of the invention, the signaling messagesent complies with the SIP protocol. It may be an “Invite” message, butalso other types of message (“Register”, “Notify”, etc.).

The parameter may be a header which complies with the SIP protocol, or aparameter which complies with the SDP protocol.

The device traversing solution may be a solution belonging to a groupincluding the mechanisms STUN, ICE, TURN, etc.

The client according to the invention may also, when the means fortraversing the address translation devices are unavailable, have themeans for adding within the sent signaling message a parameterrepresenting the non-implementation of the means of traversing addresstranslation devices.

The invention also has the objective of a communication network allowingcommunication session(s) to be set up between a calling communicationclient and a called communication client and containing at least onenetwork device. The network devices include at least one addresstranslation device and the communication network also includes means fortraversing address translation devices.

The communication network according to the invention is characterized bythe fact that in the presence, within the signaling message received, ofa parameter representing the implementation of means for the traversingof address translation devices by the communication client, the networkdevices do not implement their own means of traversing addresstranslation devices.

According to some embodiments of the invention, the signaling messagesent complies with the SIP protocol. It may be an “Invite” message, butalso other types of message (“Register”, “Notify”, etc.).

The parameter may be a header which complies with the SIP protocol, or aparameter which complies with the SDP protocol.

The device traversing solution may be a solution belonging to a groupincluding the mechanisms STUN, ICE, TURN, etc.

The communication network according to the invention may also bedesigned so that, in the absence of this parameter, the communicationnetwork devices implement their own address translation devicetraversing solutions.

It may also be envisaged that, when a device of the communicationnetwork implements its own traversing solution, it inserts a parameterinto the outgoing signaling message, with this parameter representingthis implementation.

The characteristics and the advantages of the invention will be clearerin the description which follows, together with the attached FIGURE.

This FIG. 1 shows in the form of a diagram an example of a communicationnetwork in which the invention may be implemented.

In this example of FIG. 1, the communication network is made up of 3networks SN₁, SN₂ and SN, connected by two address translation devices,NAT₁ and NAT₂. This is a standard scenario in which each communicationclient, C₁ and C₂, is connected to a private sub-network, respectivelySN₁ and SN₂. Each of these private sub-networks is connected to a publicnetwork SN using address translation devices, NAT₁ and NAT₂respectively.

Other scenarios are possible, however. For example, a single NAT addresstranslation device may be deployed between two private sub-networksbelonging to two parties of a company. A situation may also be imaginedin which one of the two clients is connected to a private sub-networkwithout use of a NAT. In this case, a single NAT address translationdevice is deployed, between the other private sub-network and the publicsub-network.

The communication network (mainly the SN public network) includes atleast one device. These devices may be IP transmission nodes, such asrouters, but also servers, signaling elements, SIP proxy, call servers,etc. On FIG. 1, for reasons of clarity, only the NAT₁ and NAT₂ addresstranslation devices, along with a call server CS, have been shown. Thiscall server CS is considered in what follows in its most generalmeaning, and therefore covers the “SIP proxy” elements, the“softswitches”, the “call controllers”, etc.

The setting up of a communication session forms part of the currentstate of the art, well known to professionals. Diagrammatically, itconsists of the stages of the transmission of a signaling messagebetween two communication clients, C₁ and C₂. This signaling flow fs issent by the call server CS located in the public network SN. Asmentioned previously, these transmissions of signaling messages allowthe exchange of the physical addresses of the communication clients C₁and C₂, and thereby allow the communication session fm to be set upbetween the two communication clients: the media flow (voice, data,video, etc.) fm may then be sent between the two clients using theseexchanged physical addresses.

The signaling messages pass through the address translation devices NAT₁and NAT₂. Therefore, each of the two communication clients C₁ and C₂ has(during a session) a public physical address assigned by the addresstranslation device to which it is attached and different to its privatephysical address.

In order to be able to establish the communication session fm, the twoclients must exchange their public physical addresses (and not theirprivate physical addresses).

We assume in the example of FIG. 1 that the calling communication clientC₁ implements an address translation device traversing solution (“NATTraversing”). By the term “implement” it is understood that not onlydoes the client possess means of traversing address translation devices,but that these means are enabled. A situation may in effect be imaginedin which these means are disabled for various reasons (failure, manualdeconfiguration as the user considers them to be under-performing,etc.).

These traversing means may be compliant with the various solutionsavailable in the existing and future state of the art, which are basedon the communication clients. The same mechanisms as mentionedpreviously, STUN, TURN or ICE, may be mentioned here.

Prior to the sending of a signaling message, the calling communicationclient C₁ adds to this message a parameter representing the fact that anaddress translation device traversing solution is implemented by theclient C₁.

In the context of implementation using the SIP protocol, this signalingmessage is usually an “INVITE” message.

The signaling message, once sent, is transmitted to the addresstranslation device NAT₁, then to other devices of the public network SN.If necessary, before reaching the address translation device NAT₁, itmay also have passed through devices of the private sub-network SN₁.

Some of these devices may have means of traversing address translationdevices. These means may be compliant with the solutions set forthpreviously: this may be an ALG gateway (Application Layer Gateway) or anSBC server (Session Border Controller).

In the presence of the parameter representing the implementation of themeans of traversing the NAT (by the client C₁) in the message received,these network devices do not implement its own means of traversing theNAT.

In this way, it ensures that once a communication client implements aNAT traversing solution, no network devices implement their ownsolution. It therefore guarantees that one and only one solution isimplemented for a given call.

This parameter added by the client to the signaling messages sent may bea header according to the SIP protocol. It may therefore take the formof a keyword followed by a value, such as the chain:

“X-Media-Processing: No-Processing”

The term “X-Media-Processing” is for indication purposes only. It may beany chain not yet used in the context of the SIP protocol and itsextensions.

The value “No-Processing” is also indicative, and specifies that noprocessing must be carried out by the network devices (in other words noimplementation of the means of traversing the NAT).

Alternatively, the parameter may be an SDP protocol (Session DescriptionProtocol) parameter. It could then take the form of a keyword followedby a value, such as the chain:

“a=media-processing no-processing”

In the event that the means of traversing the address translationdevices of the communication client C₁ are unavailable, it may:

-   -   either not add a parameter representing the implementation of a        NAT traversing solution in the signaling message sent,    -   or add a parameter representing the non-implementation of the        NAT traversing solution.

For the first option, for reasons of compatibility, the network devicereceiving a signaling message which does not contain a parameterrepresenting the implementation of a NAT traversing solution behave inaccordance with the state of the art. In other words, if they have meansof traversing the NAT, they will implement them.

For the second case, this parameter may be similar to the firstparameter.

It may for example be a SIP header which will use the same keyword asthe first parameter. It may therefore be a chain with the form:

“X-Media-Processing: Processing-Required”

The “Processing-Required” chain is indicative and means that since noNAT traversing solution is deployed by the calling communication clientC₁, a solution must be implemented by a communication network device.

This parameter may also be added as an SDP parameter, as explainedpreviously.

A calling communication client may be required to add such a parameter,if it does not have means of traversing the NAT, or if it does possesssuch means but they are unavailable (STUN server failure, etc.) orbecause the user has chosen to disable them.

When a network device has implemented a NAT traversing solution, it mayinsert into the outgoing signaling message a parameter representing thisimplementation, so that any other device which may be located in thepath of the signaling message does not also implement its own means oftraversing the NAT.

This method of producing the invention resolves the additional problemwhich may be raised by the presence of several SBC servers or ALGgateways in a communication network.

This new parameter may be implemented in different ways. It may, forexample, be a SIP header or an SDP parameter different to the onerepresenting the implementation of a traversing solution by the client.It may also be the same SIP header or the same SDP parameter, in whichcase it takes a specific value.

In the event of an implementation using a SIP header, this parameter maytake the form of the chain “X-Media-Processing: Processed”, with thekeyword “Processed” being arbitrary.

If the incoming signaling message contains a parameter (for exampleassociated with the “Processing-Requested” value), its value is modifiedby the device to become “Processed” in the outgoing signaling message.

If the incoming signaling message does not contain a parameter, themessage may add it to the outgoing signaling message.

The invention claimed is:
 1. Method of setting up a communicationsession between a calling communication client and a calledcommunication client, through a communication network including at leastone address translation device, said method including signaling messagetransmission by at least one communication client, passing the signalingmessage through said at least one address translation device andallowing the exchange of the physical addresses of said communicationclients for setting up said communication session, the methodcomprising: implementing, by at least one of said communication clients,a client traversing solution; adding, by said at least one communicationclient, a parameter representing the implementation of said clienttraversing solution within a signaling message to be sent, such that inthe presence of the parameter, the at least one address translationdevice of said communication network does not implement its owntraversing solution, the traversing solution of the at least one addresstranslation device being different from the client traversing solution;and wherein the parameter is not an address.
 2. Method of setting up acommunication session according to claim 1, wherein said signalingmessage to be sent is a message which complies with an SIP protocol. 3.Method of setting up a communication session according to claim 2,wherein said signaling message to be sent is an “Invite” compliantmessage.
 4. Method of setting up a communication session according toclaim 1, wherein said client traversing solution complies with amechanism taken within a group including at least one of STUN, TURN andICE mechanisms.
 5. Method of setting up a communication sessionaccording to claim 2, wherein said parameter is a header which complieswith the SIP protocol.
 6. Method of setting up a communication sessionaccording to claim 2, wherein said parameter is a parameter whichcomplies with the SDP protocol.
 7. Method of setting up a communicationsession according to claim 1, wherein in the absence of said parameter,the at least one address translation device implements a correspondingclient traversing solution.
 8. Method of setting up a communicationsession according to claim 7, wherein if the at least one addresstranslation device of said communication network implements its owntraversing solution, the at least one address translation device insertsa parameter into the outgoing signaling message, representing thecorresponding implementation.
 9. A communication client comprising: atransmitter configured to send signaling messages for setting up acommunication session with at least one other communication client; anda client traversing solution unit configured to traverse at least oneaddress translation device, such that prior to the sending of asignaling message, the client traversing solution unit adds within saidsignaling message a parameter representing an implementation of saidtraversal by the client traversing solution unit, and the parameter isnot an address; such that in the presence of the parameter, the at leastone address translation device is configured to refrain fromimplementing a second client traversal that is different from saidtraversal.
 10. Communication client according to claim 9, wherein saidsignaling message is a message which complies with an SIP protocol. 11.Communication client according to claim 10, wherein said signalingmessage is an “Invite” message.
 12. Communication client according toclaim 9, wherein said client traversing solution complies with amechanism taken within a group including at least one of STUN, TURN andICE mechanisms.
 13. Communication client according to claim 10, whereinsaid parameter is a header which complies with the SIP protocol. 14.Communication client according to claim 10, wherein said parameter is aparameter which complies with the SDP protocol.
 15. Communication clientaccording to claim 9, wherein, if the traversal of the at least oneaddress translation device is unavailable, the client traversingsolution unit is further configured to add within said signaling messagea parameter representing the non-implementation of said traversal. 16.Communication network for allowing the setting up of a communicationsession between a calling communication client and a calledcommunication client, the communication network comprising: at least onenetwork device including at least one address translation device; and afirst client traversing solution unit for implementing a first clienttraversing solution for traversing said at least one address translationdevice, wherein said at least one network device is configured torefrain from implementing a second client traversing solution traversingsaid at least one address translation device in the presence of aparameter representing the implementation of the first client traversingsolution by a communication client, within a received signaling message,and the parameter is not an address.
 17. Communication network accordingto claim 16, wherein said received signaling message is a message whichcomplies with an SIP protocol.
 18. Communication network according toclaim 17, wherein said received signaling message is an “Invite”message.
 19. Communication network according to claim 16, wherein saidtraversing solution complies with a mechanism taken within a groupincluding at least one of STUN, TURN and ICE mechanisms. 20.Communication network according to claim 17, wherein said parameter is aheader which complies with the SIP protocol.
 21. Communication networkaccording to claim 17, wherein said parameter is a parameter whichcomplies with the SDP protocol.
 22. Communication network according toclaim 17, wherein in the absence of said parameter, the at least onenetwork device of said communication network implements the secondclient traversing solution for the traversing of at least one addresstranslation device.
 23. Communication network according to claim 22,wherein if a network device of said communication network implements athe first client traversing solution traversing solution, the networkdevice inserts a parameter in the outgoing signaling message,representing the implementation of the first client traversing solution.24. A non-transitory computer readable storage medium storing computerprogram instructions for implementing the method according to claim 1.